home *** CD-ROM | disk | FTP | other *** search
/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / apps / 6 / gem / questfeb.doc < prev    next >
Encoding:
Text File  |  1985-11-19  |  4.0 KB  |  79 lines
  1.      Q:    Why   are   there  separate  startup   procedures   for
  2. applications and desk accessories (apstart.s and accstart.s)?
  3.  
  4.      A:   A desk accessory is started up automatically when GEM is
  5. booted,  and  becomes  more  or  less  part  of  the  system.   An
  6. application  is only run at the user's request,  after the  system
  7. has finished loading.   Since they start at different times,  they
  8. have a different "environment" to contend with.  For instance, the
  9. application  startup  code  has to release  memory  following  the
  10. program, while the accessory has this done for it by GEM.
  11.  
  12.      Q:  Can a desk accessory use a resource?
  13.  
  14.      A:   In  general,  no.   This  is because the accessories are
  15. loaded  at  system  initialization time.   If one  later  makes  a
  16. rsrc_load()  call for its resource,  the system would allocate the
  17. resource's  buffer in the user area of memory.   This would result
  18. in  a memory allocation error when the next application  attempted
  19. to run.
  20.  
  21.      However,  it is still possible to use AES object trees within
  22. an  accessory.   You should use the RCS to create the trees,  then
  23. use  the C output option to create an image of them.   This  image
  24. may  be included and compiled in the accessory's source code.   At
  25. run  time,  you will have to adjust the size of the objects  using
  26. rsrc_obfix(), as well as fix up the inter-structure pointers.  You
  27. can  use  the  source code of STCREATE.C  and  the  discussion  of
  28. resource structure in a prior column as guides.
  29.  
  30.      Q:  Are there problems with the -f (floating point) option in
  31. Alcyon C?
  32.  
  33.      A:   Yes,  there  are a number of bugs in the Alcyon floating
  34. point  library.   In  many cases,  the precision of operations  is
  35. poor.   The  only solution is to switch to Megamax or Lattice C to
  36. develop your floating point application.
  37.  
  38.      Q:  I've noticed that the HEAD, TAIL, and NEXT pointers in an
  39. object tree are actually numbers relative to the base of the tree.
  40. Does  this  mean that an object must be pre-allocated  within  the
  41. tree if I plan to objc_add() it later?  Can an application do true
  42. dynamic  allocation of objects without setting aside space in  the
  43. tree?
  44.  
  45.      A:  Yes, you must preallocate objects if you want to add them
  46. without moving the tree from the resource.   The alternative is to
  47. create  a working area from your program and copy the tree  to  be
  48. altered  to  this  buffer.   Then  you can  allocate  new  objects
  49. following  those which exist,  and link them in.   The new objects
  50. must be created on 24-byte boundaries starting at the root of  the
  51. tree.   You  do NOT need to copy over structures such as TEDINFOs,
  52. unless you plan to modify them also.
  53.  
  54.      Q:   I  am  using Hippo C,  and I can't get your downloads to
  55. work.   I'm  also  having problems with the programs in the  print
  56. edition of ANTIC.  What's going on?
  57.  
  58.      A:   Haba  Hippo-C  has  chosen  to ignore  a  number  of  ST
  59. standards, including the normal names and calling sequences of the
  60. GEM  VDI and AES calls.   It also uses source file formats and  an
  61. underlying  operating system which are incompatible with  TOS  and
  62. the  Developer's  Kit.   Due  to a lack of time,  and a desire  to
  63. promote standardization,  I will not be supporting Hippo C in this
  64. column.  If you don't want to switch to Toolkit (Alcyon), Lattice,
  65. or  Megamax C,  you will have to translate the GEM calls from  the
  66. downloads to the Hippo equivalents and probably retype the  source
  67. code into the Hippo editor.
  68.  
  69.      Q:  I'm using the Atari Developer's Kit,  and LINK68 seems to
  70. crash when my programs get large.  Is this a bug?
  71.  
  72.      A:   Yes,  there  is a known bug in using Alcyon C and LINK68
  73. when  a program's code area approaches 64K.   It appears that jump
  74. tables  generated  by  SWITCH and GOTO statements  are  not  being
  75. properly  relocated.   Often  the  difficulty can  be  avoided  by
  76. putting  such  modules at the start of the link.   Otherwise,  you
  77. will need to to recode SWITCH statements as IFs, and eliminate the
  78. GOTOs (a good practice anyway).
  79. ə